1
00:00:00,860 --> 00:00:01,820
Welcome back.

2
00:00:01,820 --> 00:00:08,570
In this lecture we're going to be taking a look at something called the unreliable remote event instance.

3
00:00:08,570 --> 00:00:09,890
Unreliable remote.

4
00:00:09,890 --> 00:00:11,660
This must be a joke right.

5
00:00:11,660 --> 00:00:15,140
Why would we ever want a remote to be unreliable?

6
00:00:15,140 --> 00:00:20,930
Well, there's actually good reason for having an instance like this inside of the Roblox API.

7
00:00:20,930 --> 00:00:25,940
And before we discuss that, we need to first understand how remote events send data to the server and

8
00:00:25,940 --> 00:00:31,010
how that compares with the unreliable remote event when remote events send information to the server,

9
00:00:31,010 --> 00:00:35,270
if the data is large enough, it will be split up into these things called packets.

10
00:00:35,270 --> 00:00:38,690
And those packets are directed towards a specific destination.

11
00:00:38,690 --> 00:00:43,250
And when they reach their destination, they're stitched back together again to get the full set of

12
00:00:43,250 --> 00:00:43,760
data.

13
00:00:43,760 --> 00:00:50,570
However, sometimes due to problems out of our control, these packets can become what's known as lost

14
00:00:50,570 --> 00:00:51,020
meaning.

15
00:00:51,020 --> 00:00:56,900
The recipient of these packets never received them, so regular remote events will keep resending those

16
00:00:56,900 --> 00:01:01,190
packets until it has confirmed that the recipient received the packets.

17
00:01:01,190 --> 00:01:06,170
The problem with this is that it can clog the pipe of data trying to be sent through a remote event,

18
00:01:06,170 --> 00:01:12,230
as the remote event will prioritize making sure a packet reaches its recipient before sending another

19
00:01:12,230 --> 00:01:13,010
set of data.

20
00:01:13,010 --> 00:01:17,240
This can lead to network latency and poor user experience in your games.

21
00:01:17,240 --> 00:01:20,360
Now, this is mostly true if you're firing remote events rapidly.

22
00:01:20,360 --> 00:01:27,020
If you need to fire a remote event rapidly and you care more about improved network latency over packet

23
00:01:27,020 --> 00:01:30,560
loss, then that's what we use unreliable remote events for.

24
00:01:30,560 --> 00:01:35,360
As an example, think of the TCP and UDP internet protocols.

25
00:01:35,360 --> 00:01:42,800
The purpose of TCP is to send data in an orderly fashion, and it ensures that data reaches its destination.

26
00:01:42,800 --> 00:01:47,120
This makes it transfer data slower, but it's extremely reliable.

27
00:01:47,120 --> 00:01:53,450
UDP, on the other hand, is not reliable like TCP, as it does not check to make sure that a packet

28
00:01:53,450 --> 00:01:54,950
reaches its destination.

29
00:01:54,950 --> 00:01:59,360
The main goal of UDP is to get data out as fast as possible.

30
00:01:59,360 --> 00:02:04,370
So while UDP is less reliable, it is much faster than TCP.

31
00:02:04,430 --> 00:02:09,050
This same idea can be thought of with remote events and unreliable remote events.

32
00:02:09,080 --> 00:02:13,460
Remote events are reliable, ordered and send data slower and unreliable.

33
00:02:13,460 --> 00:02:19,310
Remote events send data very quickly and unordered, and they aren't concerned about packet loss.

34
00:02:19,310 --> 00:02:24,890
Now that we have a good idea of what the purpose of the new unreliable remote event is for, you may

35
00:02:24,890 --> 00:02:26,990
be wondering when would I ever use it?

36
00:02:26,990 --> 00:02:33,170
Well, there are many cases you may want to use an unreliable remote event as an example for replicating

37
00:02:33,170 --> 00:02:38,390
effects across the client server boundary, or sending data to the server rapidly and quickly to update

38
00:02:38,390 --> 00:02:40,220
something that all clients need to see.

39
00:02:40,220 --> 00:02:45,140
Let's say you had a fire extinguisher tool, and you would like to be able to control the direction

40
00:02:45,140 --> 00:02:51,170
of particles coming out of the fire extinguisher based on the position of the mouse on a player screen.

41
00:02:51,170 --> 00:02:56,780
Well, in order for the server to be able to know where the mouse is on a player's screen, the player

42
00:02:56,780 --> 00:02:59,030
has to send that data to the server.

43
00:02:59,270 --> 00:03:02,690
Depending on how fast you want the particle direction to update.

44
00:03:02,690 --> 00:03:08,120
If you tried to fire the position of the mouse rapidly using a regular remote event, you'll probably

45
00:03:08,120 --> 00:03:10,010
run into some network congestion.

46
00:03:10,010 --> 00:03:14,180
But if you use an unreliable remote event, you can fire it rapidly.

47
00:03:14,180 --> 00:03:19,010
And you don't have to worry about network congestion because if the packet is lost, it's fine because

48
00:03:19,010 --> 00:03:21,950
the next packet will probably make it to the destination.

49
00:03:21,950 --> 00:03:24,320
Another example could be with a vehicle system.

50
00:03:24,320 --> 00:03:29,690
It's commonly stated that you should try to have the client do as much heavy lifting as possible, and

51
00:03:29,690 --> 00:03:31,220
have the server do the least.

52
00:03:31,220 --> 00:03:34,670
That way your game does not become laggy with a vehicle system.

53
00:03:34,670 --> 00:03:40,400
Let's say the playback speed of the sound for the engine needs to be updated depending on the speed

54
00:03:40,400 --> 00:03:41,210
of the vehicle.

55
00:03:41,210 --> 00:03:46,340
If you had the server checked this and you had many players in your game with lots of vehicles, you

56
00:03:46,340 --> 00:03:49,430
could end up running into performance issues on the server.

57
00:03:49,430 --> 00:03:51,290
What would be the fix for this?

58
00:03:51,290 --> 00:03:56,810
Have the speed checks be done on the client, and have the client send information to the server via

59
00:03:56,810 --> 00:04:02,150
an unreliable remote event to tell the server how fast the engine sounds playback should be.

60
00:04:02,150 --> 00:04:07,040
There are many more uses for unreliable remote events, but those were just a couple to demonstrate

61
00:04:07,040 --> 00:04:08,900
the use of an unreliable remote event.

62
00:04:08,900 --> 00:04:14,630
Let's go ahead and create a tool where the client can control the direction of particles coming out

63
00:04:14,630 --> 00:04:15,080
of it.

64
00:04:15,290 --> 00:04:18,380
So let's go ahead and create a new tool inside of the starter pack.

65
00:04:18,380 --> 00:04:21,530
I'm not going to name it anything because this is just a demonstration tool.

66
00:04:21,530 --> 00:04:23,300
And then let's go ahead and create a part in here.

67
00:04:23,300 --> 00:04:24,710
This is going to be my handle.

68
00:04:24,710 --> 00:04:26,300
So we'll name it to handle.

69
00:04:26,300 --> 00:04:28,850
And then I'm going to make sure I disable Can Collide.

70
00:04:28,850 --> 00:04:31,610
And then inside of this handle I'm going to add an attachment.

71
00:04:31,610 --> 00:04:34,070
And this is where my particle emitter is going to be.

72
00:04:34,070 --> 00:04:40,370
And what we're going to do is we're going to have the particle emitter emit from the front of our attachment.

73
00:04:40,370 --> 00:04:41,960
So we'll set it to front.

74
00:04:41,960 --> 00:04:47,750
And then we're going to update the keyframe of this attachment to be looking towards wherever our player's

75
00:04:47,750 --> 00:04:48,320
mouse is.

76
00:04:48,320 --> 00:04:52,700
So that way the particle emitters are emitting in the direction of the player's mouse.

77
00:04:52,700 --> 00:04:54,860
I'll also decrease the size of the handle.

78
00:04:54,860 --> 00:04:58,010
I'll just make it 0.5 by 0.5 by 0.5 studs.

79
00:04:58,010 --> 00:05:00,080
And then let's go ahead and create a server script.

80
00:05:00,200 --> 00:05:00,890
Than here.

81
00:05:00,890 --> 00:05:02,990
We're going to need a local script as well.

82
00:05:02,990 --> 00:05:06,320
And then we're going to create an unreliable remote event.

83
00:05:06,320 --> 00:05:10,040
And I'm going to name this update inside of my local script.

84
00:05:10,040 --> 00:05:14,450
Let's go ahead and get the player service so we can grab the local player, because we're going to need

85
00:05:14,450 --> 00:05:15,770
the player's mouse object.

86
00:05:15,770 --> 00:05:20,360
And then we're also going to grab the run service because I want to fire to the server every single

87
00:05:20,360 --> 00:05:20,990
heartbeat.

88
00:05:20,990 --> 00:05:24,680
So let's go ahead and get the player which is player is that local player.

89
00:05:24,680 --> 00:05:27,410
We'll get the mouse, get mouse.

90
00:05:27,410 --> 00:05:31,040
And then we'll also go ahead and make a reference to the tool which is script dot parent.

91
00:05:31,400 --> 00:05:36,500
And then when the tool is equipped what we want to do is we want to start listening to the run service

92
00:05:36,500 --> 00:05:37,280
heartbeat event.

93
00:05:37,280 --> 00:05:41,480
And then when the tool is unequipped, we stop listening to the heartbeat event.

94
00:05:41,480 --> 00:05:45,380
So let's go ahead and listen to both the equipped and unequipped event.

95
00:05:46,040 --> 00:05:50,360
And then up here we're going to listen to Run Service Heartbeat.

96
00:05:50,360 --> 00:05:52,280
And we're going to connect a function to it.

97
00:05:52,280 --> 00:05:56,810
And all this is going to do is we're going to refer to our unreliable remote event.

98
00:05:56,810 --> 00:06:00,170
And this has the exact same functions as a regular remote event.

99
00:06:00,170 --> 00:06:02,690
So we can fire to the server some information.

100
00:06:02,690 --> 00:06:06,410
And that information is going to be the position of our mouse in the workspace.

101
00:06:06,410 --> 00:06:09,830
So we can refer to mouse dot hit and get the position.

102
00:06:09,830 --> 00:06:11,630
And that's all the server is going to need.

103
00:06:11,630 --> 00:06:16,340
And then when we unequip our tool we want to make sure we disconnect this function from our heartbeat

104
00:06:16,340 --> 00:06:16,610
event.

105
00:06:16,610 --> 00:06:19,130
So let's go ahead and store a connection in a variable.

106
00:06:19,130 --> 00:06:20,780
Let's declare it up here.

107
00:06:20,780 --> 00:06:22,100
Call it connection.

108
00:06:22,100 --> 00:06:24,740
And then connection is going to be equal to that.

109
00:06:24,740 --> 00:06:27,770
And then when we unequip it we can check if we have a connection.

110
00:06:27,770 --> 00:06:32,510
And if we do we'll make sure to disconnect that and set it equal to nil.

111
00:06:32,510 --> 00:06:36,050
And then we can do the exact same thing up here just in case.

112
00:06:36,470 --> 00:06:40,130
Now inside of the server script let's go ahead and make a reference to our tool.

113
00:06:40,130 --> 00:06:41,600
So script dot parent.

114
00:06:41,810 --> 00:06:45,200
And then we're just going to listen to our unreliable remote event.

115
00:06:45,200 --> 00:06:47,270
And we're going to get the on server event.

116
00:06:47,270 --> 00:06:50,300
So just like a regular remote event we'll connect.

117
00:06:50,300 --> 00:06:52,190
We'll get that player that fired the event.

118
00:06:52,190 --> 00:06:55,220
And then hopefully we'll also get past a mouse position.

119
00:06:55,220 --> 00:07:00,620
And now what we can go ahead and do is we can calculate what the keyframe should be for our attachment.

120
00:07:00,620 --> 00:07:02,960
And we're going to use keyframe dot look at.

121
00:07:02,960 --> 00:07:07,790
And we're going to be using the position of the attachment in our handle looking towards the position

122
00:07:07,790 --> 00:07:08,510
of our mouse.

123
00:07:08,510 --> 00:07:11,930
So let's refer to tool dot handle dot attachment.

124
00:07:11,930 --> 00:07:14,090
And then we're going to get world position.

125
00:07:14,300 --> 00:07:17,450
And we're going to have it look towards our mouse position.

126
00:07:17,450 --> 00:07:21,710
Then we can go ahead and set the handle dot attachment.

127
00:07:21,710 --> 00:07:26,090
We want to update its world keyframe equal to the keyframe that we just calculated.

128
00:07:26,090 --> 00:07:27,410
So we'll store that in a variable.

129
00:07:27,410 --> 00:07:28,910
We'll call it Look Keyframe.

130
00:07:29,960 --> 00:07:33,230
And then that's what we'll update the attachment to.

131
00:07:33,230 --> 00:07:38,720
So now every single heartbeat on the client, we're going to be firing to the server to update the position

132
00:07:38,720 --> 00:07:40,940
or I mean the rotation of our attachment.

133
00:07:40,940 --> 00:07:45,950
So that way all the particles coming out of the attachment is going to be following the position of

134
00:07:45,950 --> 00:07:46,520
our mouse.

135
00:07:46,520 --> 00:07:48,590
So let's go ahead and try it out.

136
00:07:48,590 --> 00:07:52,280
If we play test our game here's our tool if I equip it.

137
00:07:52,980 --> 00:07:54,420
There's our particles coming out.

138
00:07:54,420 --> 00:07:55,920
And if you notice, look at that.

139
00:07:55,920 --> 00:07:57,930
It's going towards the direction of our mouse.

140
00:07:57,930 --> 00:08:03,450
If I move my mouse over here now, the particles are moving towards again the direction of my mouse.

141
00:08:03,450 --> 00:08:09,960
And now I have total control over the direction of particles coming out of my tool, which is very cool.

142
00:08:09,960 --> 00:08:14,220
I can point it up in the sky and the particles will move in that direction.

143
00:08:14,220 --> 00:08:16,860
I can point it over here and over here.

144
00:08:16,860 --> 00:08:17,640
Look at that.

145
00:08:17,640 --> 00:08:23,130
And since all we're sending to the server is the position of my mouse to update the keyframe of the

146
00:08:23,130 --> 00:08:28,410
attachment, it doesn't really matter if we lose a couple of packets here and there, because it's not

147
00:08:28,410 --> 00:08:30,180
a crucial game mechanic.

148
00:08:30,180 --> 00:08:36,420
If you have any crucial game mechanics where you need information from the client to reach the server,

149
00:08:36,420 --> 00:08:38,880
then yeah, use a regular remote event.

150
00:08:38,880 --> 00:08:43,770
But for situations like this where all you need to do is like update a particular thing or some visual

151
00:08:43,770 --> 00:08:44,130
effect.

152
00:08:44,130 --> 00:08:46,350
Yeah, use unreliable remote events.

153
00:08:47,060 --> 00:08:48,710
That's all from me in this lecture.

154
00:08:48,710 --> 00:08:51,860
I hope you enjoyed and I'll see you in the next one.